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ABSTRACT 

Decision  Support  Systems  (DSS)  have  been  identified  as  a 
solution  to  the  military  commander's  needs  for  information 
filtering  and  analysis.  Current  literature  on  the  theory  and 
techniques  of  DSS  design  have  been  addressed  to  the  decision- 
making processes  of  commercial  applications.  The  lack  of  a 
comprehensive  treatement  of  military  command  and  control 
decision-making  requirements  may  result  in  a  number  of 
command  and  control  DSS  which  are  not  designed  for  the 
reliability  and  flexibility  required  in  a  context  of  ever- 
changing  threats.  This  thesis  is  an  initial  attempt  to 
identify  some  unique  considerations  for  the  design  of  a 
command  and  control  decision  support  system  and  offers 
suggestions  towards  the  development  of  flexible,  reliable 
systems  to  serve  commanders  in  both  peacetime  and  combat 
operations. 
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I.   INTRODUCTION 

The  Navy  has  been  using  computers  longer  than  any  other 
organization.  The  Harvard  Mark  I  and  the  ENIAC  were 
providing  data  for  ballistic  studies  in  the  late  1940's. 
Since  then,  the  Navy  has  become  dependent  on  computers  for 
virtually  all  its  essential  activities  from  payroll  to 
weapons  control  [Ref.  1:  pp.  6-7].  While  such  extensive 
employment  of  computing  capabilities  has  without  doubt 
allowed  the  Navy  to  run  a  leaner,  more  capable  operation,  it 
has  also  resulted  in  the  same  "information  overload"  problem 
which  has  received  so  much  publicity  in  the  business  press. 

Managers  and  businessmen  in  the  private  sector  have  long 
complained  that  the  so-called  Management  Information  Systems, 
or  MIS,  have  had  little  or  no  beneficial  effect  on  managerial 
decision-making.  Managers  do  not  need  more  data;  they  need  a 
way  to  filter  data,  to  view  it  from  different  angles,  to  make 
projections,  and  to  conduct  variance  and  sensitivity 
analyses.  The  concept  of  Decision  Support  Systems  (DSS)  , 
which  was  made  possible  in  the  late  1960's  with  the 
introduction  of  time  sharing  and  remote  terminals,  provided 
the  potential  for  managers  to  use  information  "instead  of 
being  buried  under  it"  [Ref.  2:  p.  33  ]. 


Most  discussion  of  the  use  of  DSS  to  support  military 
decision-making  is  limited  to  proposals  and  suggestions. 
While  several  projects  are  underway  to  field  prototype  DSS, 
the  actual  capability  to  perform  analyses  on  data  is  usually 
planned  for  later  versions  of  the  system.  This  is  especially 
true  for  systems  which  will  support  such  complex  and 
dif f icult-to-def ine  missions  such  as  command  and  control. 

Still,  the  need  is  there;  commanders  on  ships  and  in  the 
field  are  just  as  inundated  with  data  as  any  other  manager, 
if  not  considerably  more  so.  DSS  promises  to  help  these 
commanders  filter  information,  analyze  data,  compare 
alternatives  and  transmit  commands,  all  from  the  same 
console. 

The  Soviets  also  see  the  need  for  command  and  control 
DSS.  Fleet  Admiral  Gorshkov  shares  our  Secretary  of 
Defense's  opinion  that  the  status  of  a  force's  Command  and 
Control  elements  will  be  an  equally  important  determinant  in 
war  as  that  of  the  level  of  technology  of  weapons  systems 
[Ref.  3:  p.  7,  Ref.  4:  p.  241].  Gorshkov  recently  presented 
a  paper  in  which  he  identifies  the  modeling  and  analytical 
capabilities  of  a  Command  and  Control  decision-supporting 
computer  system  as  capabilities  which  will  be  essential  to 
permit  commanders  to  make  decisions  in  an  environment  which 
will  be  distinguished  by  the  "large  spatial  scope, 
accelerated  tempo,  and  sharp  variation  in  the  situation...." 


With  a  well-established  need,  and  with  the  increasing 
recognition  of  the  importance  of  Command  and  Control,  it  is 
not  at  all  surprising  that  the  concept  of  Command  and  Control 
DSS  has  already  attracted  much  attention  in  the  Navy. 
Unfortunately,  current  textbooks  and  actual  DSS  examples  are 
strictly  commercial  applications  for  such  purposes  as 
financial  and  production  management.  Military  planners  or 
project  managers  who  will  be  responsible  for  the  design 
specifications  of  Command  and  Control  DSS  will  find  very 
little    in   the   way  of   formal  guidance. 

The  purpose  of  this  research,  then,  is  to  consolidate 
what  information  available  in  the  scattering  of  applicable 
articles  in  military  journals  with  this  author's  knowledge  of 
Navy  command  and  control  to  provide  a  general  outline  of 
unique  considerations  in  the  design  of  a  Command  and  Control 
DSS.  It  is  hoped  that  this  thesis  will  also  serve  to 
stimulate  further  interest  and  research  towards  more  complete 
and    formal    textbooks   or    manuals   on    the    subject. 
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II.   A  PLACE  FOR  DSS  IN  COMMAND  AND  CONTROL 

Command  and  control  has  always  been  an  important  element 
in  war,  and  in  this  age  of  nuclear  weapons  and  the  need  for 
instant  response,  it  has  become  even  more  important.  Soviet 
Fleet  Admiral  Gorshkov  emphasizes  the  role  of  command  and 
control  in  warfare,  "Disrupting  enemy  control  of  forces  in  a 
number  of  instances  can  produce  no  less  an  effect  than  their 
immediate  defeat..."  [Ref.  3:  p.  9]. 

The  current  administration  has  recognized  this  critical 
role  of  command  and  control.  In  his  Annual  Report  to  the 
Congress  for  Fiscal  Year  1984,  Defense  Secretary  Weinberger 
emphasizes  the  dependence  of  force  capability  upon  command 
and  control  systems  [Ref.  4:  p.  241].  Roughly  $15  billion  a 
year  is  now  being  invested  in  these  systems,  making  command 
and  control  the  fastest  growing  functional  component  of  the 
U.S,  defense  budget  [Ref.  5:  p.  28]. 

A.   TODAY'S  COMMAND  AND  CONTROL  SYSTEMS:   THE  CHALLENGE 

As  Secretary  Weinberger  states  in  the  FY  1984  Report, 
"The  variety  and  complexity  of  our  C3I*  systems  presents  us 
with  an  extremely  challenging  management  task"  [Ref,  4:  p. 
241].   Most  of  our  command  and  control  systems  evolved 


*"C3I"  is  the  acronym  for  Command,  Control,  Communica- 
tions, and  Intelligence. 
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independently  and  are  supported  by  a  collection  of  equipment 
whose  architectures  are  15  to  30  years  oldf  with  low  meantime 
between  failure  and  high  maintenance  costs.  Like  many  other 
military  computer  systems  they  involve  software  which  is 
"non-portable,  inflexible  and  largely  unresponsive,  expensive 
to  develop  and  maintain,  with  little  or  no  interoperability 
and  few  standards.."  [Ref.  6:  p.  26].] 

The  challenge  today  is  to  upgrade  and  integrate  current 
command  and  control  systems  and  to  develop  and  acquire  new 
systems  which  [Ref.  4:  pp.  241-242]: 

-  provide  a  "proper  mix"  with  weapons  systems, 

-  can  evolve  with  changing  needs  for  information, 

-  are  affordable, 

-  meet  the  requirements  of  the  decisionmakers  they  will 
serve, 

-  are  survivable  in  both  lethal  and  electronic  warfare, 

-  are  interoperable,  both  among  our  own  Services  and  with 
our  allies,  in  joint  and  combined  military  operations, 

-  are  consistent  with  long  range  plans  developed  jointly 
with  the  Defense  Intelligence  Agency  and  the  JCS. 

Obviously,  such   goals  will  not  be  achieved  overnight. 

Command  and  control  is  a  very  complex  mission.   Robert  B. 

Doane  of  the  Air  Force  Systems  Command's  Electronic  Systems 

Division  states  that  before  it  will  be  possible  to  develop  a 

satisfactory  command  and  control  architecture,  it  is  first 

necessary  to  undertake   "...a  concerted  effort  to  define, 

with  a  degree  of  stability,  the  top-level  information  needs 
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for  all  levels  of  command,  ...from  the  'local1  (battle) 
commanders  up  through  the  JCS — a  very  difficult  task"  [Ref. 
7:    p.    182]. 

B.       DIFFERENT    CONCEPTS    OF    COMMAND   AND    CONTROL 

Still  others  say  that  command  and  control  defies  precise 
definition,  [Ref.  8:  pp.  96]  and  that  the  "absence  of  a 
succinct  statement  of  objectives"  at  the  national  level  has 
resulted  in  command  and  control  systems  which  have  been 
driven  instead  by  the  push  for  technological  sophistication. 
[Ref.    9:    pp.    48-69]  . 

There    are    indeed    many    different    concepts    of    command    and 

control.    The   JCS   Pub   1    offers    this    definition: 

"The  exercise  of  authority  and  direction  by  properly 
designated  commanders  over  assigned  forces  in  the 
accomplishment  of  his  mission.  Command  and  control 
functions  are  performed  through  an  arrangement  of 
equipment,  communication,  facilities  and  procedures  in 
planning,  directing  and  controlling  forces  and  operations 
in    the    accomplishment    of    his    mission"    [Ref.     7:    p.    182]. 

Another   definition    of    command    and    control    emphasizes    the 

process    of    decision-making    [Ref.    10:    p.    15]: 

"..a  process:  or,  more  accurately,  a  set  of  related 
processes.  It  is,  first,  a  process  of  getting  information 
to  decision  makers.  Second,  it  is  a  process  of 
interaction    between    decision    makers.  Third,      it     is    a 

process  of  implementing  their  decisions.  All  three  of 
these  vital  processes  are  centered  around  decision  makers: 
the  task  of  command  and  control  is  to  help  them  see  more 
clearly  what  is  happening,  decide  what  to  do  about  it  and 
implement   the   necessary   actions.  " 

It    is    this    latter    definition    which,     in    the    opinion    of 

this    writer,     will    best    support    efforts    to    design    integrated 
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command  and  control  systems.  Its  emphasis  on  the  decision 
maker  is  more  promising  in  achieving  Secretary  Weinberger's 
goal  of  developing  systems  which  will  serve  the  information 
needs  of  the  intended  users.  Its  division  of  the  process  of 
command  and  control  into  the  three  '  subpr ocesses '  of 
gathering  information,  interaction  among  decision-makers  and 
Am£i:£m£H-t.Al!Si  decisions  highlights  the  importance  of 
communications  in  command  and  control  decision  making.  It 
also  closely  resembles  Simon's  paradigm  of  decision  making* 
and  thus  allows  inspection  of  current  command  and  control 
systems  as  to  how  well  they  support  each  of  the  three  stages 
of   decision    making. 

C.       COMMAND   AND    CONTROL    DECISION-MAKING 

The  decision-making  phases  identified  by  Simon  are  the 
"intelligence"  phase,  the  "des ign".  phase  and  the  "choice" 
phase.  The  decision-making  process  involves  the  iteration  of 
these  phases,  where  "intelligence"  is  the  gathering  of  data, 
"design"  is  the  manipulation  and  analysis  of  the  data,  and 
"choice"  is  the  selection  and  implementation  of  a  course  of 
action. 

The  intelligence  phase  of  decision-making  in  command  and 
control,  or  the  gathering  of  information  is  already  well- 
supported    by    sophisticated    sensors    and    communications 


*See  Appendix,  Section  C. 
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technology.  It  is  the  design  and  choice  phases,  in  which 

alternatives  are  evaluated  and  implemented,  where  current 

command  and  control  systems  provide  little  support  for 

commanders.   The  Assistant  Secretary  of  the  Navy  (Research, 

Engineering  and  Systems),  John  Paisley  was  quoted  in  SIGNAL 

Magazine  [Ref.  11:  p.  23]: 

"Our  ability  to  collect,  process  and  transport  information 
at  prodigious  rates  is  great  and  continues  to  expand  and 
already  has  exceeded  our  ability  to  assimilate  and 
comprehend.  The  commander. ..has  more  information  than  he 
can  use.  The  difficulty  is  that  the  information  is  not 
always  in  the  right  form  or  presentation  and  it  may  not  be 
available  'in-time,1  but  without  question,  he  has  more  than 
he  can  use." 

Commanders  must  be  provided  some  means  for  "assessment, 

aggregation  and  correlation  of  vasts  amounts  of  data"  and 

some  way  of  "filtering  the  essentials  to  decision  makers  at 

every  level"  [Ref.  12:  p.  18].   Without  such  a  means  to 

manage  this  "information  explosion",  decision-makers  faced 

with  complex  decisions  and  short  time  frames  must  rely  soley 

on  their  own  heuristic  problem-solving  abilities  which  are 

limited  by  small  short  term  memory  capacity  and  the  serial, 

one-process-at-a-time  mode  of  operation  [Ref.  13:  p.  40]. 

Because  the  nature  of  modern  warfare  involves  tremendously 

fast  and  accurate  weapons,  there  will  be  no  time  to  perform 

this  relatively  slow  mental  problem-solving  process  for 

optimal  solutions.   While  "satisf icing, "  or  "settling  for  a 

good-enough"  solution  may  serve  the  needs  of  other  decision 

makers  [Ref.  14:  p.  449],  it  is  not  a  desirable  method  for 
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problem-solving  when  the  consequences  can  affect  the  lives  of 
men  or  the  defense  and  reputation  of  the  country. 

The  heuristic  process  of  human  decision-making  can  also 
result  in  distortions  or  biases  [Ref.  15:  p.  119].  The 
decision  maker  will  search  for  relevant  information,  but  will 
use  only  that  which  can  be  made  available  in  the  given  time 
frame.  He  may  interpret  data  differently  depending  on  the 
order  or  method  of  presentation.  He  may  select  for  retention 
only  that  data  or  information  which  he  understands,  or  in 
which  he  has  particular  interest  or  knowledge.  His 
expectations  may  prevent  him  from  accepting  the  significance 
of  contradictory  information.  The  frequency  of  recent  events 
can  cause  the  decision  maker  to  overlook  the  more  crucial 
measure  of  rate  of  occurance.  Variables  may  be  erroneously 
correlated  and  inferences  can  be  inappropriately  derived  from 
insignificantly  small  samples.  These  are  just  a  few  of  the 
problems  associated  with  unaided  human  decision  making.  The 
consequences  for  command  and  control  decisions  could  be  at 
best  inefficient,  at  worst,  disastrous. 

D.   DSS  FOR  COMMAND  AND  CONTROL 

One  method  to  improve  the  effectiveness  of  command  and 
control  decision  making  while  eliminating  at  least  some  of 
these  human  biases,  is  to  provide  commanders  with  decision 
support  systems  [Ref.  16:  p.  45].  A  prototype  DSS,  the 
Tactical  Flag  Command  Center  (TFCC)  ,   is  currently  under 
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development  and  will  provide  Navy  Officers  in  Tactical 
Command  a  "battle  station  which  is  automated  to  assimilate 
and  display  organic  and  non  organic  sensor  tactical  data"  and 
will  "enable  him  to  coordinate  and  control  assigned  tasks  in 
the  increasingly  complex  tactical  situations..."  [Ref.  17:  p. 
32-33].  Other  such  systems  are  being  planned  to  support 
commanders    in   all   services. 

Evidently  the  need  to  support  decision  makers  in  all 
three  phases  of  decision  making  has  been  recognized.  DSS  may 
well  be  the  answer.  However,  the  fielding  of  such  systems 
cannot  be  done  successfully  without  careful  planning  and 
integration  into  an  overall  systems  architecture.  Command 
and  control  systems  must  be  interoperable  and  survivable  if 
they  are  to  serve  decision  makers  in  combat  environments. 
They  must  be  integrated  with  complex  weapons  systems  and  thus 
incorporate  some  well-defined  strategies  and  tactics. 
Furthermore,  they  must  be  affordable  and  take  into 
consideration    life    cycle   costs   of    maintenance. 

The  design  of  command  and  control  DSS  is  much  more 
complicated  than  that  of  a  DSS  intended  for  commercial  uses. 
The  following  chapter  will  attempt  to  identify  some  of  the 
major  difficulties  associated  with  developing  such  a  system 
for    command   and   control. 
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III.       FITTING   A    DSS    INTO   THE    COMMAND   AND    CONTROL 
ARCHITECTURE:       ORGANIZATIONAL   AND    TECHNICAL 
CONSIDERATIONS 

A.       IMPLEMENTING   NEW   TECHNOLOGY 

A  DSS  cannot  be  bought  'off  the  shelf  and  simply 
"plugged  in."  Instead,  the  design  and  implementation  must 
involve  analyses  of  (1)  the  implicit  affects  upon  the  users 
and  upon  the  context  or  organization  in  which  they  operate, 
and  (2)  limitations  or  requirements  imposed  by  the  supporting 
technology.  Too  often,  the  implementation  of  a  new 
technology  has  been  viewed  as  a  "discrete-entity"  process  in 
which  the  technical  merits  of  the  new  system(s)  would 
determine  effectiveness,  independently  of  the  specific 
characteristics  of  the  organization  [Ref.  18:  pp.  7-8].  Such 
a  practice  is  at  least  partly  responsible  for  the  lack  of 
integration  of  the  various  components  of  the  current  command 
and    control    architecture    [Ref.    19:    p.    16]. 

A  DSS  is  a  form  of  technology  in  that  it  is  a  technique 
by  which  an  organization  or  individual  transforms  inputs  to 
outputs  and  which  involves  equipment,  automation,  and 
problem-solving  methods.  Thus,  the  implementation  of  a  DSS 
can  "require  subsequent  changes  in  task,  structure  or 
individual"  [Ref.  20:  p.  126].  Some  of  these  changes  may  be 
easily  predicted,    some   easily  quantified   in   terms   of   cost. 
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More  thoughtful  analyses  usually  result  in  the  identification 
of  affects  which  are  not  readily  quantified  in  terms  of 
expected  costs    [Ref.   21:  p.   223]. 

An  attempt  to  estimate  the  costs  associated  with  the 
implementation  of  a  DSS  for  command  and  control  purposes  in 
the  military  will  be  very  difficult,  for  there  has  been  very 
little  effort  to  develop  a  theory  of  current  command  and 
control  decision  making  processes  [Ref.  8:  p.  45-49,  Ref.  22: 
p.  45-49].  A  cost/benefit  analysis  would  be  extremely 
difficult,  if  not  impossible,  without  some  understanding  and 
ability  to  quantify,  for  purposes  of  comparison,  the 
effectiveness  of  the  current  methods  of  command  and  control 
decision-making. 

It  is  possible,  and  highly  advisable  when  introducing  a 
new  system  into  an  environment  characterized  by  high 
technology  and  low  structure  (low  level  of  integration),  that 
some  attempt  is  made  to  identify  the  "area  of  change"  and 
perform  what  is  has  come  to  be  known  as  a  "risk  analysis" 
[Ref.  23:  p.  325].  Such  a  risk  analysis  is  undertaken  for 
early  identification  of  potential  problem  areas  and 
appropriate  managerial  or  technical  means  by  which  to  lessen 
the    risks. 

This  chapter  presents  some  organizational  and  technical 
factors  which  may  require  consideration  by  those  who  are 
responsible    for    the   development   of   a   command    and  control  DSS. 
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The  list  is  by  no  means  complete,  for  depending  on  the 
particular  situation  and  environment  there  will  probably  be 
more  specific  factors  which  will  also  require  attention.  The 
intent  here  is  to  develop  an  appreciation  for  some  of  the 
generally-applicable,  but  often  neglected,  organizational  and 
technical  factors  which  can  affect  the  performance  of  a  DSS 
in  a  command  and  control  setting. 

B.   ORGANIZATIONAL  FACTORS 
1.   Strategic  Balance 

Dramatic  improvements  in  our  command  and  control 
capabilities  could  have  the  effect  of  negating  or  reducing 
one  or  more  perceived  advantages  of  an  adversary's  weapons 
capabilities  [Ref.  24:  p.  4,  Ref.  25:  p.  248].  It  would  then 
be  possible  that  the  new  command  and  control  capability  may 
itself  become  the  subject  of  strategic  arms  negotiations 
[Ref.  26:  p.  424].  If  the  DSS  should  incorporate  real-time 
satellite  data  for  an  improved  ability  to  "scan  the 
battlefield,"  it  may  well  raise  questions  as  to  whether  this 
will  increase  or  decrease  the  likelihood  that  nuclear  weapons 
will  be  used  [Ref.  27:  p.  26].  The  impact  of  new  command  and 
control  capabilities  on  the  strategic  balance  and  on  arms 
talks  will  largely  depend  on  whether  the  new  capabilities  are 
perceived  by  our  adversaries,  especially  the  Soviet  Union,  as 
offensive  or  as  defensive  capabilities  [Ref.  25:  p.  246]. 
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2.   Centralized  vs.  Decentralized  Command  Authority 

Depending  on  the  communications  capabilities  provided 
in  the  design,  a  command  and  control  DSS  may  further  the 
trend  towards  centralization  of  command  authority.  If  the 
DSS  is  designed  to  meet  the  objective  of  enhancing 
communications  among  the  various  echelons  of  command,  it  may 
provide  central  headquarters  authorities  with  rapid  feedback 
of  subordinate  actions  and  with  the  ability  to  monitor  in  a 
real-time  manner,  the  behavior  and  events  at  the  lower 
echelons  [Ref.  20:  p.  177].  This  will  be  viewed  favorably  by 
those  who  feel  that  the  threat  of  escalation  to  nuclear 
exchange  mandates  central  control  during  any  conflict  [Ref. 
20:  p.  141,  Ref.  28:  p. 8,  Ref.  29:  p.  266].  Others  argue 
that  commanders  at  the  level  of  engagement  have  neither  the 
time  nor  the  inclination  to  accept  control  from  remote 
authority  [Ref.  30:  p.  45,  Ref.  31:  p.  23,  Ref.  32:  p.  20]. 

Computers  themselves  do  not  enforce  centralization  or 
decentralization  of  authority.  The  choice  is  one  of  strategy 
and  politics.  The  issue  has  already  attracted  much  debate 
and  has  produced  concepts  of  command  and  control  which  differ 
as  to  degree  and  location  of  control  and  responsibility.  The 
Composite  Warfare  Commander  and  the  Fleet  Command  Center 
concepts  are  two  examples,  the  former  advocating 
decentralization  of  control  of  warfare  mission  areas  to  at 
least  3  warfare  commanders,  the  latter  holding  that  control 
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by    safely    remote    experts    will    simplify    decision-making    for 
on-scene   commanders. 

Before     it     will     be     possible     to     establish     the 
information    requirements    of    the    users    of    a    proposed    command 
and  control  DSS,    it   will   be   necessary   to   agree  on   this   aspect 
of  command    [Ref.   33:   p.    31,    Ref.    34:    p.    418]. 
3.      Defense   Strategy 

If  the  DSS  is  to  provide  the  commander  with  such 
capabilities  as  threat  evaluation,  targeting  prioritization, 
and  situation  analysis,  it  will  necessarily  involve  models 
which  cannot  be  designed  without  a  clear  definition  of 
defense  strategy  and  associated  tactics.  Critics  argue  that 
no  such  clearly  defined  strategy  exists  [Ref.  35,  Ref.  36: 
pp.  9-12,  Ref.  37,  Ref.  38:  p.  14].  Others  suggest  that 
current  strategy  has  fallen  out  of  step  with  the  new  threats 
and  new  weapons  capabilities,  especially  in  that  forces  and 
tactics  are  organized  for  a  war  of  attrition  when  modern 
warfare's  dispersed  and  decentralized  characteristics  more 
appropriately  call  for  maneuverability  and  deception  [Ref. 
39:    p.    18,    Ref.    40:    p.    33,    Ref.    41]. 

The  role  of  command  and  control  capabilities  and 
facilities  in  supporting  the  defense  strategy  must  also  be 
defined  in  order  to  design  and  implement  an  effective  command 
and    control   DSS.       Today      there    are    no   clear    statements    of 
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objectives  for  command  and  control  support  of  the  forces 
[Ref.  9:  p.  52], 

4.   Interoperability 

In  the  past,  disregard  for  the  interdependencies  of 
various  command  and  control  systems  has  resulted  in  "separate 
programs,  different  rates  of  evolution,  different 
protocols.."  [Ref.  19:  p.  18].  Don  Latham,  DUSD  for  C3I, 
referred  recently  to  the  almost  unbelievable  interoperability 
problems  which  have  resulted.  The  present  command  and 
control  resources  "must  be  integrated  into  an  overall  plan  to 
insure  efficient  employment  and  to  avoid  duplication  of 
capabilities  in  future  procurement"  [Ref.  42:  p.  2], 

Interoperability  of  command  and  control  systems  is 
not  an  issue  which  can  be  addressed  as  an  afterthought. 
Modern  warfare  with  its  broad  area  sensors  and  long  range 
weapons  requires  that  information  be  rapidly  and  reliably 
exchanged  among  systems  at  a  variety  of  levels  of  command, 
between  forces  of  the  various  services  and  between  the  United 
States  and  its  allies  [Ref.  43:  p.  45].  It  may  even  be 
advisable,  considering  the  confusion  and  uncertainty 
surrounding  the  scene  of  future  warfare  [Ref.  44]  and  the 
constant  threat  of  escalation,  that  our  command  and  control 
systems  be  designed  for  "adversarial  communications,"  or 
interoperability  with  non-friendly  forces  [Ref.  45:  p.  90], 
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While  it  may  be  neither  feasible  nor  desirable  to 
design  a  given  DSS  for  interoperability  with  all  of  the  major 
systems,  identification  of  desirable  connectivity  in  the 

early  stages  of  the  system  development  cycle  will  reduce 
costly  efforts  to  upgrade  the  system  for  such  a  capability  at 
a  later  date. 

5 .   Command  Responsibility 

The  research  involved  in  the  preparation  of  this 
thesis  uncovered  not  a  single  mention  of  the  issue  of 
responsibility  for  results  of  command  decisions  which  are 
based  on  the  information  provided  by  a  command  and  control 
DSS.  Nevertheless,  the  issue  seems  worth  mentioning;  perhaps 
it  will  be  raised  officially  once  DSS  actually  become 
operational  in  command  and  control  settings. 

If  the  commander  today  is  to  be  provided  with  a  set 
of  models  and  data  to  help  him  deal  with  the  so-called  data- 
explosion,  then  will  he  still  be  held  responsible  for  the 
accuracy  of  those  models  and  data?  If  the  DSS  is  to  be  used 
under  combat  or  crisis  situations,  will  the  commander  be 
expected  to  assess  the  validity  of  the  results  of  his  queries 
to  the  system.  It  is  not  inconceivable  that  an  error  in  the 
design  of  a  model,  or  in  the  transparent  data  source  could  go 
undetected  until  the  investigation  which  would  follow  an 
unfortunate,  and  possibly,  a  very  costly,  decision. 
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Clarification  of  this  issue  before  asking  commanders 
to  use  a  DSS  may  at  least  serve  to  develop  in  those 
commanders  a  desire  to  fully  understand  the  models  and 
capabilities  provided  by  the  system.  To  neglect  this  issue 
is  to  risk  reinforcement  of  a  common  tendency  to  distrust 
both  models  and  computers — a  result  which  will  negate  the 
potentials   of   DSS    in   command   and   control. 

C.       TECHNICAL    CONSIDERATIONS 

Command  and  control  systems  must  be  both  reliable  and 
flexible.  The  degrees  of  reliability  and  flexibility  needed, 
and  the  ability  to  achieve  them,  is  largely  a  function  of  the 
particular  uses  and  operating  environments  of  each  system. 
The  operating  environment  of  a  tactical  command  and  control 
system  presents  more  design  problems  than  that  of  a 
strategic  system  due  to  the  more  restrictive  availability  of 
maintenance  support,  power,  and  space  aboard  mobile 
platforms.  The  following  technical  considerations  for  the 
design  of  a  command  and  control  DSS  are  discussed  in  terms  of 
flexibility  and  reliability  and  apply  specifically  to 
tactical  systems.  Some  of  these  comments  may  prove  equally 
applicable    to   strategic   systems. 

1.      Flexibility 

The  rapidly  changing  nature  of  the  command  and 
control  environment  and  of  computer  hardware  and  software 
technology    calls    for    a    great    deal    of    flexibility    in    the 
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components  of  the  DSS.  The  modular  concepts  of  software 
engineering  as  described  by  Constantine,  Myers  and  Stevens 
[Ref.  46:  pp.  115-138]  will  be  useful  for  a  command  and 
control  DSS.  The  basic  idea  is  to  design  the  system  as  a  set 
of  loosely-coupled  segments  where  any  one  function  is  fully 
contained  within  a  single  segment,  or  module.  This  allows 
the  isolation  into  separate  modules  of  the  various  likely 
"areas  of  change."  The  same  modular  concept  can  be  applied  to 
the  design  of  the  hardware  components  at  the  box,  board  or 
chip  level  [Ref.  39:  p.  2],  While  the  details  of  the 
processing  techniques  should  be  left  to  the  contractor,  the 
modular  approach  to  design  can  be  specified  in  the  contract 
as    a   mandatory   equipment   specification    [Ref.    47]. 

The    following    points    emphasize    the    need    for    command 
and      control   software    to   be   designed    for    flexibility: 

1.  Algorithms    and    data    may    need    frequent    revision 

due    to    the    rapidly    changing    capabilities    and    nature    of 
weapons  systems  and  threats.      Modular   software,    with   its 

separation     of     "areas     of     change,"     will     greatly     reduce 

reprograming  effort  and  cost  and   will   lessen   the    risk   of 

negatively   affecting   other   portions   of    the   software. 

2.  User  needs  vary  across  users  and  individually 
over  time.  Some  users  prefer  graphic  displays  over 
tabulated  data.  Some  users  will  need  more  "help" 
instructions  to  operate  the  systems.  Some  will  become 
expert  users  with  experience  and  would  become  frustrated  if 
there  were  no  means  to  bypass  the  more  basic  help 
instructions    for    faster    response    [Ref.    48:    pp.     16-17]. 

3.  The  decision-making  processes  for  peacetime 
operations  are  distinctly  different  from  those  which  are 
necessary  for  combat  operations  [Ref.  49:  p.  93,  Ref.  50: 
p.  15].  The  DSS  should  support  both  of  these  decision- 
making   processes    and    provide    for    a    smooth    transition    from 
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one  to  the  other.  This  means  that  while  the  system  should 
provide  different  models,  data  and  response  times,  it 
should  not  require  any  major  changes  in  operation. 

4.  The  system  will  require  changes  as  more  is 
learned  about  command  and  control  decision-making  in 
general,  and  as  the  user  provides  feedback  as  to  how  the 
system  could  better  meet  his  needs.  Current  knowledge  of 
command  and  control  decision-making  is  incomplete,  and  as 
weapons  and  tactics  undergo  constant  changes,  the  study  of 
such  decision-making  will  be  an  ongoing  effort  [Ref.  22:  p. 
34,  Ref.  8:  p.  96]. 

5.  A  modular  design  will  reduce  software  maintenance 
efforts,  which  typically  account  for  an  estimated  67%  of 
total  effort  expended  on  large-scale  software  systems  [Ref. 
51:  p.  204].  Maintenance  involves  correcting  newly- 
discovered  errors,  performing  planned  updates  and  making 
adjustments  for  change  in  local  conditions  (such  as  changes 
in  the  hardware).  Approximately  70%  of  the  total  cost  of 
software  systems  over  the  life  cycle  occurs  during  this 
maintenance  stage  [Ref.  51:  p.  204].  This  figure  could 
increase  if  the  current  upward  trend  in  the  cost  of 
programming  continues  [Ref.  46:  p.  136].  Simplified 
software  maintenance  is  also  particularly  important  for 
tactical  systems  due  to  the  difficulty  in  providing  skilled 
personnel  to  perform  the  maintenance  and  due  to  the  impact 
of  downtime  on  mission  performance. 

6.  A  modular  software  design  will  permit  separation 
of  the  communications  processing  subsystem  and  thus  allow 
for  flexibility  in  sources  of  data  input  [Ref.  52:  p.  96]. 
This  is  an  important  consideration  since  communications 
media  are  subject  to  both  natural  disturbances  and,  in 
conflict,  intentional  disruption.  The  communications 
subsystem  should  be  readily  and  easily  reprogr amable  for 
such  changes  and  should  have  no  affect  on  the  rest  of  the 
system,  save  perhaps  a  short  time  delay. 

7.  If  the  database  is  limited  by  storage  capacity, 
it  may  be  desirable  to  provide  off-line  disk  storage  for 
different  communications  subprocessing  programs,  models, 
and  data  files. 

2.   Reliability 

A  command  and  control  DSS  will  no  doubt  be  a  great 

decision-making  aid  in  peacetime.    The  commander  will 
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appreciate  a  system  which  helps  him  filter  and  make  effective 
use  of  all  the  data  available  to  him.  He  will  also  grow 
accustomed  to  have  such  aid.  The  DSS  would  be 
counterproductive,  however,  if  it  ceases  to  function  during  a 
combat  situation  when  he  may  most  need  it.  It  is  therefore 
necessary  to  take  every  precaution  to  "harden"  the  system  and 
to  ensure  the  integrity  and  availability  of  its  supporting 
data,  models  and  hardware.  The  following  discussions  of 
hardware,  communications  and  data  model  reliability  will 
point  out  some  of  the  potential  problems  which,  if  considered 
during  the  early  development  stages,  can  be  countered  with 
appropriate  hardware  and  software  techniques, 
a.   Hardware  Reliability 

Defense  system  requirements  are  vastly  different 
from  those  of  the  commercial  sectors.  Command  and  control 
systems,  in  particular,  require  very  reliable  and  rapid 
processing  of  real  time  data  streams  [Ref.  53:  p.  358]. 
Furthermore,  defense  systems,  especially  tactical  systems, 
are  constrained  by  weight,  power,  and  size  limitations  and 
are  subjected  to  far  more  extreme  environmental  hazards  such 
as  high  temperatures,  radiation  and  vibration  [Ref.  54:  p. 
346]  . 

The  introduction  of  new  hardware  to  support  a 
command  and  control  DSS  provides  an  opportunity  to  improve 
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reliability   through    the   use   of    'Very   Large   Scale    Integration1 
or    'Very   High    Scale    Integrated    Circuitry'     (VHSIC). 

(1)  VHSIC  Technology.  Commercial  semi-conductor 
designs  cannot  meet  the  speed,  density  and  reliability 
requirements  of  a  command  and  control  system  [Ref.  55:  p. 
340].  The  VHSIC  program  was  initiated  in  1980  by  the 
Department  of  Defense  to  overcome  these  technological 
barriers  with  the  more  capable  chip.  The  new  chips  will 
provide  more  processing  capability  and  higher  throughput 
capacity.  The  reduction  in  vulnerable  interconnections  among 
chips  which  results,  serves  to  increase  reliability.  The 
reduction  in  feature  size  of  integrated  circuits  on  these 
chips  also  allows  for  built-in  testing  techniques  which  can 
greatly  simplify  maintenance--  a  distinct  advantage  in  the 
tactical    field    [Ref.     56:     p.     344]. 

(2)  EMP  Shielding.  Solid  state  circuitry  is 
very  vulnerable  to  electromagnetic  pulsing.  Most  new  command 
and  control  systems  programs  have  set  aside  funds  for 
protective  Faraday  shielding  at  the  "box"  level.  The  larger 
the  "box,"  the  more  expensive  the  shielding.  VHSIC  will 
greatly  reduce  the  sizes  of  these  components,  or  boxes,  and 
thus  provide  savings  in  shielding  costs  [Ref.  57:  p.  240, 
Ref.    5:    p.    27]. 

(3)  Hardware  Maintenance.  Although  the  reli- 
ability   of    individual    electronic    components     in    military 
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systems   has    steadily    improved   over    the  years,    the   complexity 

of  these  systems  has  grown  even  more  rapidly  as   a   result  of 

escalating  performance  demands.      The   amount   and  complexity  of 

unscheduled    maintenance    is    unacceptable    and    degrades    mission 

performance      [Ref.      58:     p.      11,      Ref.      59:     p.      15].     VHSIC 

technology    promises     to    greatly     improve    performance     and 

reliability    as     well     as     the     extra    advantages    of    reduced 

"pay load: " 

"...VHSIC  technology  could  be  used  to  reduce  size,  weight, 
power,  failure  rate,  and  unit  cost,  each  by  factors  ranging 
from  20  to  200;  the  processing  throughput  could  be 
increased    by    a    factor    of    about    150"    [Ref.    56:    p.    343]. 

b.      Data  Communications   Reliability 

(1)      The    Problem.      Much  of  the  data  needed   for  a 

command     and     control     DSS     will     be     provided     by     real-time 

transmission     over     communications     media.         As     mentioned 

earlier,    the   DSS   should   not   be   affected   by   the   need   to   switch 

to   an   alternate   path   or    medium    in    the   case   of    signal    loss   on 

the    original    path.       It    is    also    necessary    to    plan    for    the 

inability  to  reestablish  communications,    or    the  complete   loss 

for    an   extended   period   of   time   of   critical  data   sources. 

Signal    degradation    and    path    failure    occur 

even    in   peace    time   due   to   equipment   failure   and    inclement 

weather.       The    probability    of    losing    communications    circuits 

increases   greatly   when  hostile   forces  deliberately  attempt  to 

jam,     interfere    or    otherwise    sabotage       communications 

capabilities    and     facilities.        Threats    range     from     the 
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destruction   of    fixed   communications    stations  and   satellite 

earth     terminals     to     laser     attacks     on     the     satellites 

themselves.       The    Soviets    are    developing    laser-capable 

spacecraft  which  will   threaten  our   communications   satellites, 

and  already  they  have  the  capability  to  blind  our   low-orbit 

(100   miles)    satellites   with   their   land-based   laser   devices 

[Ref.      60:      pp.      16-19].      The     threat     to     our        satellite 

communications    capabilities    is    an    especially    serious    threat 

to   the  Navy  as    its    tactical  command  and  control   is  heavily 

reliant   upon      satellite    links    [Ref.    61:    p.    49]. 

A    NATO    official    describes    the    vulnerability 

of  the  data  communications   which  support   the  NATO  Air  Command 

and  Control  System    (ACCS)    [Ref.   62:   p.   16]: 

"We  see  as  a  critical  and  vulnerable  element  of  the  ACCS 
the  su seep  tab i 1 i ty  to  jamming  of  its  tactical 
communications  links,  with  the  probability  that  the  flow  of 
essential  weapon  control  data  would  disrupted  and  the 
decision  making  process  would  be  seriously  inhibited  at  all 
levels." 

The   October    issue   of   Defense    '82   describes 

the    vulnerability   of    "the    major    part,     if    not    all,     of    our 

existing    C3    capability"    to      a    coordinated    Soviet    attack    with 

air    and    sea-launched    cruise    missiles    and    long-range    bombers 

[Ref.    63:    p.    8].      Nuclear    weapons   pose   an   even   greater    threat 

in    that   Electromagnetic   Pulses    (EMP)       can   be   carried    for    long 

distances    in    unpredictable    directions    by    the    atmospheric 

pressures.      EMP    is    known    to   have    the    effect    of    "freezing" 

solid   state  circuitry,    at   least      temporarily.      A  small   two 
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megaton  burst  can  damage  an  unprotected  satellite  up  to 
22,500  miles  away  [Ref.  64:  p.  27]. 

(2)  Solutions,  Lt.  General  William  J.  Hilsman, 
Director,  Defense  Communications  Agency,  expressed  his 
concerns  in  a  recent  interview  that  the  military 
communications  system  is  too  heavily  reliant  on  fixed 
communications  stations.  Both  he  and  the  NATO  ACCS  officials 
support  the  theory  that  modern  day  warfare  would  be  better 
supported  by  distributed  data  communications  which  do  not 
rely  on  the  continued  operation  of  any  one  node.  Already 
some  C3  systems  ,  such  as  the  Joint  Tactical  Information 
Distribution  System,  are  being  developed  to  facilitate 
secure,  flexible  and  jam-resistant  data  and  voice  transfer  in 
real  time  among  the  dispersed  and  mobile  elements  of  the 
military  services  [Ref.  65:  pp.  15-17].  The  concept  of  data 
distribution  has  not  been  easily  accepted.  It  may  be  many 
years  before  the  communications  system  architecture  can  be 
changed  for  less  reliance  on  fixed  stations,  due  to 
bureaucratic  and  organizational  inertia  and  the  general 
difficulty  in  getting  command  and  control  systems  approved 
and  funded  through  Congress  [Ref.  58:  pp.  11,  14]. 

The  use  of  high  frequency  (HF)  communications 
links  will  also  add  appreciably  to  the  probability  of 
successful  communications.  The  reliability  in  peacetime 
operations  of  satellite  links   and  the  memories  of  once 
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unreliable  HF  path  quality  have  resulted  in  the  neglect  of 
the  HF  frequency  band.  The  new  "chirp-sounder"  equipment, 
currently  being  fielded  by  the  Defense  Communications  Agency, 
has  increased  HF  path  reliability  to  90%  [Ref.  58:  p.  12]. 
Chirp  sounders  automatically  sample  the  spectrum  for  tuning 
into  good  frequencies.  Also,  the  HF  spectrum  has  a  unique 
capability  to  propagate  beyond  line-of-sight  using  reasonable 
size  antennas  and  relatively  modest  output  power. 

Command  and  control  DSS  should  be  designed 
to  take  advantages  of  the  capabilities  of  the  HF  frequency 
band  as  either  a  primary  system  or  as  backup  to  a  satellite 
or  other  relay  system.  Jamming  resistance  can  be  provided  by 
the  use  of  frequency-hopping  techniques  and  coded  burst 
communication  [Ref.  66:  pp.  380-388]. 

Communications  reliability  can  be  also  be 
improved  by  the  use  of  redundant  transmissions  or  dedicated 
back-up  circuits.  An  analysis  of  information  needs  and 
available  communications  paths  should  identify  the  most 
survivable  paths  and  backups  for  the  high  priority  data 
needs.  The  DSS  can  then  be  designed  to  accommodate  these 
communications  media  and  to  allow  for  flexibility  to  make 
necessary  changes.  The  data  analysis  may  also  indicate  a 
need  to  develop  contingency  plans  for  cases  when 
communications  cannot  be  reestablished  for  particular 
circuits.   The  loss  of  data  may  mean  the  inability  to  use 
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certain  models  available  in  the  DSS.  The  commander  should  be 
aware  of  the  affects  of  data  communications  loss  on  DSS 
operation  and  of  possible  alternate  methods  of  receiving  data 
(over    voice   circuits)    for    possible    manual    insertion. 

The  point  here  is  planning.  The  Soviets 
have  invested  heavily  in  Electronic  Counter  Measures,  or  what 
they  call  "Radio  Electronic  Combat"  [Ref.  67:  p.  10].  Until 
our  C3  systems  are  fully  survivable,  it  would  be  dangerous  to 
allow  commanders  to  become  accustomed  to  or  dependent  on  a 
decision-making  system  whose  operation  is  dependent  on  the 
availability  of  vulnerable,  limited  data  sources,  without 
providing  contingency  plans. 
c.      Model   Reliability 

Models  are  what  distinguishes  a  DSS  from  other 
information  management  systems.  A  command  and  control  DSS 
will  employ  models  to  integrate  data  from  a  variety  of 
sources,  including  real-time  sensor  sources,  for  the  purpose 
of  situation  analysis.  Models  may  also  be  provided  within 
the  DSS  for  performing  combat  simulations  for  planning 
purposes. 

Thus  models  used  in  a  command  and  control  DSS  can 
range  from  the  straight- for  ward  algorithms  used  in 
calculating  distance-to-target  to  the  more  complex,  multiple 
variable,  multiple  algorithm  models  of  threat  evaluation.  A 
Comptroller    General    Report    to    the    Congress     [Ref.     38] 
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distinguishes  models  as  those  which  solve  "rigorously 
quantifiable"  problems  and  those  which  solve  "squishy 
problems. " 

While  all  models  are  subject  to  design  errors,  it 
is  the  "squishy"  problem-solving  models  which  deserve 
particular  attention  by  those  who  intend  to  have  them 
incorporated  into  a  command  and  control  DSS.  Once  these 
models  have  been  approved  for  the  system,  the  intended  users 
should  also  be  made  aware  of  both  the  capabilities  and 
limitations  of  each  model.  Where  possible  it  is  even 
advisable  to  provide  for  user  participation  in  the  design  of 
models.  User  understanding  is  important  both  for  building 
trust  in  the  system  and  for  avoiding  gross  misinterpretation 
of  results  [Ref.  68:  p.  57]. 

(1)  Assumptions  in  Models.  Modelling  is  more  an 
art  than  a  science.  It  is  impossible,  in  many  cases,  to 
quantify  some  of  the  variables  which  contribute  greatly  to 
the  outcome  of  events,  such  as  the  effects  of  darkness  or 
stress,  the  complex  interactions  of  weapons  systems,  and  the 
roles  of  C3  and  counter-C3.  In  other  cases,  it  is  necessary 
to  omit  even  some  quantifiable  variable  inputs  due  to  the 
inability  to  process  all  the  inputs  in  the  necessary  time 
frame.  The  model-builder  must  determine  which  variables  are 
the  most  critical  and  of  those,  which  can  be  included 
included  for  realistic  processing  times.   His  or  her 
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assumptions,  then,  are  one  of  the  weaknesses  inherent  in  the 
modelling  process  [Ref.  68:  p.  56]. 

(2)  Data  Verification.  Another  basic  weakness 
is  the  inability  to  verify  data.  Many  of  the  calculations 
performed  by  combat  models  depend  on  quantifiable  performance 
ratios  of  various  weapons  systems.  Some  of  these  weapons 
have  had  very  little  testing  under  realistic  conditions. 
Nuclear  weapons  have  undergone  virtually  no  realistic 
testing.  Even  where  data  is  available,  it  is  subject  to 
frequent  change  and  rapidly  outdated  by  weapons  system 
technology.  Sources  for  weapons  data  have  sometimes  been 
historical,  often  from  unlocatable  or  inaccessible  classified 
documents.  Some  figures  are  sheer  estimates  on  the  part  of 
analysts.  Currently  there  exists  no  single  complete  source 
of  weapons  data;  the  Command  and  Control  Technical  Center  in 
the  Pentagon  has  just  recently  begun  to  establish  such  a 
data  bank.  The  lack  of  standard  data  has  resulted  in  models 
which  vary  widely  throughout  the  Department  of  Defense  [Ref. 
69:  pp.  73-78].. 

(3)  Aggregated  Models.  Aggregated  models  are 
perhaps  the  "shakiest"  of  all  models.  They  lump  together 
similar  types  of  weapons  into  a  composite  index  which  is  then 
used  to  represent  the  combat  power  of  a  military  force.  Both 
the  model  and  the  input  data  for  such  aggregation  involve 
critical  assumptions  about  tactics,   rates  of  fire  and 
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distribution  of  that  fire  [Ref.  69:  p.  56].   Use  of  such 
models  should  be  for  general  planning  and  comparison  purposes 

only. 

(4)  Model  Interpretation.  If  the  builders  of 
models  could  explain  and  document  their  assumptions  to  the 
end  users,  the  current  problem  with  interpretation  might  be 
somewhat  alleviated.  As  it  is,  modellers  have  limited  and 
infrequent  contact  with  users  or  their  organizations  [Ref. 
69:  p.  31]  and  documentation  is  as  much  a  neglected  item  as 
it  has  been  with  most  other  Department  of  Defense  software 
systems. 

(5)  Combining  Models.  In  defining  information 
needs,  it  sometimes  seems  desirable  to  utilize  outputs  of  one 
model  as  inputs  to  another  [Ref.  69:  p.  79].  It  can  be  done, 
but  experts  warn  that  the  programming  effort  will  be 
horrendous  [Ref.  70:  p.  99,  Ref.  71:  p.  340].  Furthermore, 
errors  in  the  first  model  can  be  so  compounded  by  subsequent 
models    as    to    invalidate    the    results    [Ref.    68:    p.    57]. 

(6)  Model    Validation.       A   last    warning,     from    a 

NATO    operations    analyst    who    creates    combat    models    for    a 

living,     should    emphasize    the    uncertainty    inherent    in    the 

processes    of    modelling    [Ref.    68:    p.    55]: 

..in  spite  of  the  intellectual  resources  devoted  on  both 
sides  of  the  Atlantic  to  modelling  techniques,  there  is  no 
agreed,  coherent  theory  or  set  of  criteria  by  which  one  can 
asses    the   suitability  of   any  given   model. 
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The     point     in     this     section     on     Model 

Reliability    is   not    to   discount    the    advantages   or    deny    the 

need   for   the  use  of  models,   but   instead,    to  develop  a   sense 

of  caution   in  order   that  command  and  control   DSS   designers 

will  demand  documentation  of   assumptions    in   models   and  of 

data    sources    for    models    which    will    eventually    support    a 

decision    maker's    judgement,     for    [Ref.    69:    p.    73]  : 

..  when  that  judgement  is  'extended'  by  a  model  --  a  model 
that  uses  unverified  assumptions  that  go  beyond  science  and 
objective  fact — how  can  the  decision  maker  be  sure  that 
the  model  is  in  fact,  serving  as  an  extension  of  his/her 
own  judgement... 

The    next    chapter    on    implementation   presents 

the  concept  of  a  command   and   control   system   test   bed.      The 

test  bed  simulates   the  command  and  control  environment  and 

could   be   used    as   one   check    for    validity   of    models.       The    real 

test     will    be     actual    combat     use.        Careful    design     and 

documentation   will    reduce    the    risk   of   costly   error    in    actual 

use. 
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IV.   COMMAND  AND  CONTROL  DSS  IMPLEMENTATION 

The  evolutionary  or  prototype  approach  to  implementation 

of  a  DSS  is  especially  applicable  to  systems  designed  for 

command  and  control  purposes: 

...every  design  problem  begins  with  an  effort  to  achieve 
fitness  between  two  entities:  the  form  in  question  and  its 
context.  The  form  is  the  solution  to  the  problem;  the 
context  defines  the  problem.  In  other  words,  when  we  speak 
of  design,  the  real  object  of  discussion  is  not  the  form 
alone  but  the  ensemble  comprising  the  form  and  its 
context.  Good  fit  is  a  desired  property  of  this  ensemble 
into  form  and  context  [Ref.  72:  p.  33]. 

Fitting  a  DSS  into  the  very  complex  context  of  command 

and  control  will  require  the  flexibility  of  an  evolutionary 

development  approach.   While  government  regulations  and  the 

military  personnel  turnover  problem  will  complicate  the 

implementation  process,  the  results  of  a  prototyping  approach 

will  better  meet  commanders'  decision-making  needs  in  the 

rapidly  changing  command  and  control  setting. 

A.   THE  TRADITIONAL  APPROACH  TO  IMPLEMENTATION 

The  traditional  approach  to  systems  acquisition  and 
implementation,  still  used  for  most  command  and  control 
systems,  follows  a  sequential  approach  from  requirements 
definition,  to  advanced  development,  to  fielding  and  support. 
Even  when  this  sequence  of  events  is  iterated,  the  ultimate 
goal  is  the  "freezing  of  the  specs"  in  the  requirements 
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definition  phase.  While  this  traditional  process  seems 
reasonable  for  weapons/platform  acquisition,  it  is  not 
advisable  in  unstructured  settings  [Ref.  73:  pp.  1-8]  as  it 
intimidates  the  decision-makers,  forces  premature  closing  on 
problem-solving  approaches,  and  inhibits  the  important 
learning  and  search  processes  that  are  essential  for  managers 
to  undertake  in  addressing  less  strctured  tasks. 

In  general,  DSS  will  experience  a  very  short 
periodicity —  or  serviceability--bef ore  requiring  hardware, 
or  more  likely,  software  changes  for  restructuring,  updating 
or  expansion  [Ref.  73:  p.  5].  The  following  characteristics 
apply  to  command  and  control  systems  and  should  serve  to 
explain  their  short  periodicity  [Ref.  74:  pp.  19-20]: 

-  Only  a  few  of  a  kind  are  procured. 

-  The  systems  are  embedded  in  larger  systems. 

-  The  measures  of  success  are  difficult  to  define. 

-  Continuity  of  operations  is  essential. 

-  The  systems  embody  changing  tactics  and  procedures. 

-  The  systems  are  software-dominated. 

A  seventh  characteristic  which  affects  command  and 
control  systems  periodicity  is  the  unpredictability  of 
funding  [Ref.  58:  p.  14].  Planned  capabilities  may  have  to  be 
dropped  when  funds  are  cut  in  the  eleventh  hour. 

Thus  a  command  and  control  DSS  will  be  a  unique  set  of 
software,  custom  tailored  but  flexible  enought  to  meet  the 
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specific  decision-making  styles  and  information  requirements 
of  a  commander  who  operates  in  an  unpredictable  and  rapidly 
changing  environment.  It  would  be  very  difficult  to 
determine  at  once  all  the  objectives  of  a  given  system  or  how 
the  users  will  respond  to  particular  configurations  and 
capabilities. 

B.  PROTOTYPING 

The  prototype  approach  accommodates  these  uncertainties 
by  phased  implementation  of  versions,  where  the  first  version 
is  a  "breadboard"  or  minimum  requirements  system.  The 
determination  of  the  minimum  requirements  will  require 
considerable  time  and  effort  up  front  [Ref.  74:  p.  25]. 
Subsequent  versions,  providing  funding  is  available,  can  add 
new  capabilities,  make  modifications,  or  incorporate 
advantages  of  new  hardware  or  software  technologies,  all 
based  on  user  feedback  from  in-context  testing.  The  concept 
of  modular  hardware  and  software  design  is  highly  compatible 
with  the  prototyping  approach  to  implementation.  Together, 
these  techniques  can  produce  a  system  which  is  designed  from 
the  start  to  accommodate  growth  and  change  and  to  accept 
"graceful  insertion"  of  new  technologies  [Ref.  75:  p.  39]. 

C.  BENEFITS  OF  PROTOTYPING 

Some  of  the  benefits  of  prototyping  are,  briefly  [Ref. 
76:  p.  65]  : 
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1.  Reduction  of   Total   Cost 

Over  one-half  of  the  total  software  in  command  and 
control  systems  tends  to  be  unique,  costly,  one-time 
development  efforts.  The  modular  approach  to  implementation, 
with  its  built-in  expectation  of  change,  reduces  overall 
development    and    maintenance    costs    [Ref.    77:    p.    50]. 

2.  Reduction  of  Initial  Risk 

Instead  of  dedicating  large  dollar  amounts  and  human 
resources  to  a  long-term,  "one-shot"  program  which  defies 
evaluation  until  completion,  prototyping  allows  minimum 
initial  investments  and  constant  evaluation.  Success  at  each 
stage  could  make  the  next  stage  easier  to  justify  and  fund. 
Errors  are  more  easier  and  less  costly  to  track  to  sources, 
and  corrections  of  errors  are  less  likely  to  cause  unexpected 
changes   elsewhere    in    the   system. 

3 .  Slower  Obsolescence 

Changes  in  tactics,  weapons  or  other  decision-making 
criteria  will  not  render  the  system  obsolescent  as  it  can  be 
more  readily  adjusted  to  accommodate  those  changes. 

4.  Higher  Operational  Readiness 

Prototyping  can  provide  for  the  early  fielding  of 
minimum  capabilities  rather  than  the  long  delay  in  waiting 
for  an  entire  system  to  be  developed. 
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D.   RESOURCE  REQUIREMENTS  FOR  PROTOTYPING 

The  prototyping  approach  requires  the  availability  and 
skilled  use  of  advanced  software  techniques  in  order  to 
facilitate  the  many  changes  to  versions.  The  following 
resources  will  provide  programming  and  design  advantages 
which  can  speed  the  development  effort  and  prevent  the 
problems  of  constantly  "reinventing  the  wheel"  with  each 
version  [Ref.  72:  p.  34]: 

1.  DBMS 

A  database  management  system  (DBMS)  will  provide  for 
rapid  and  relatively-easy  creation,  revision,  and  extension 
of  data  access  methods,  storage  structures  and  security 
measures.  Ideally,  the  DBMS  will  have  extensive  reporting 
facilities  for  design  management  purposes. 

2.  Generalized  Input/Output  Software 

Output  formats  and  displays  can  be  more  rapidly 
designed  with  the  use  of  report  generators,  report  writers 
and  query  languages.  Generalized  input  software  automates 
the  editing,  validation  and  error  correction  procedures  which 
would  otherwise  complicate  and  lengthen  the  process  of 
changing  the  database. 

3 .  Programming  Languages 

While  most  command  and  control  algorithms  may  require 
the  efficiency  of  assembly  language,  high  level  languages  can 
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be    used    where   efficiency   is   not   paramount,    for    simplified 
coding,    testing    and    documentation. 

4.  Modelling 

The  need  for  models  has  already  been  discussed.  The 
use  of  a  model  base  management  system  for  the  integration  of 
models  into  a  "model  bank"  is  advisable  for  rapid 
construction    and    use    of    models    [Ref.    70:    pp.    98-110]. 

5.  Time 

To  the  above  resources  as  offered  by  Naumann  and 
Jenkins,  it  seems  necessary  to  add  the  element  of  time  as  a 
resource.  Prototyping  depends  on  user  evaluation  in  context. 
Thus  the  user  must  be  able  to  dedicate  sufficient  time,  away 
from  his  other  duties,  to  experiment  with  and  evaluate  each 
version.  For  some  command  and  control  systems  it  may  prove 
difficult  to  test  versions  on  the  very  platforms  in  which 
they  will  operate.  Tight  operating  schedules  may  indicate 
the  need  to  make  use  of  a  command  and  control  test  bed  to 
simulate  the  intended  operational  environment  [Ref.  78:  pp. 
103-106] . 

E.   DISADVANTAGES  OF  PROTOTYPING 

All  methods  have  drawbacks.   The  following  disadvantages 
apply  to  prototyping  for  most  DSS  [Ref.  79:  p.  22]: 

-  Large  amount  of  user  time  required 

-  Requires  highly  talented  system  designer 

-  Possible  reprogramming  needed  for  efficiency 
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-  Lack     of     standards     and     documentation     can     complicate 
maintenance 

-  Highly   susceptible   to  user/implementer    turnover 

-  Continuous   change   can   be    frustrating 

-  Unweildy  with  more   than   2   or    3    users 

The  user/designer  turnover  problem  is  one  that  the 
military,  with  its  policy  of  rotation,  will  have  to  live 
with.  In  at  least  one  DSS  case,  it  has  resulted  in  the 
complete  failure  of  the  system  [Ref.  80:  pp.  542-455].  The 
other  problems  mentioned  by  Alter,  can  be  approached  with 
good  planning  and  use  of  resources  and  the  establishment  of 
good    user-designer    relations. 

A  problem  not  mentioned  by  Alter,  and  probably  unique  to 
federal  systems  acquisition,  is  the  difficulty  in  getting 
away  from  the  traditional  systems  development  process.  A  new 
Department  of  Defense  Instruction  5000.2  for  evolutionary 
acquisition  has  not  been  applied  consistently  "partly  because 
the  concept  of  evolutionary  acquisition  is  not  well 
understood,  and  partly  because  of  resistance  to  the  special 
management  procedures  and  changes.. which  are  required"  [Ref. 
81:    p.    9]. 

F.       SUMMARY 

The  rapidly  changing  environment  which  distinguishes 
command  and  control  calls  for  an  acquisition  and 
implementation    strategy   which    allows    for   greater    flexibility 
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and  user  involvement  than  is  possible  with  the  traditional 
phased  development  process.  Personnel  turnover  and  rigid 
governmental  acquisition  regulations  may  complicate  the 
process,  but  the  prototype  approach  to  implementation  seems 
the  most  promising  for  the  accommodation  of  change,  growth 
and  new  technology  insertion,  as  well  as  budget  limitations, 
of  command  and  control  systems. 
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V.   SUMMARY  AND  CONCLUSIONS 

Command  and  control  DSS  have  the  potential  to  fulfill  the 
information  requirements  of  individual  commanders  while  also 
filling  the  gap  of  distributed  decision-making  between 
service  echelons  and  across  service  systems.  Already  there 
is  a  strong  movement  underway  to  apply  the  concept  of  DSS  to 
command  and  control  purposes.  The  command  and  control  DSS 
which  are  currently  under  development  are  breaking  new 
ground.  There  is  as  yet,  no  one  source  of  guidance  for  the 
designers  or  project  managers  of  these  systems.  Current 
texts  have  been  written  for  strictly  commercial  purposes 
such  as  banking  and  finance.  These  texts  provide  a  wealth  of 
information  about  the  design  techniques  used  in  creating  DSS, 
but  do  not  address  issues  which  are  critical  for  the  design 
of  military  DSS. 

Military  decision-making  involves  several  echelons  of 
command  authority,  real-time  communications-dependent  data, 
highly  unpredictable  events  and  results  which  can  affect 
national  defense.  For  these  reasons,  careful  consideration 
must  be  given  in  the  early  development  phases,  of  the 
following  issues: 

-  The  affects  of  the  DSS  on  the  organization's  decision- 
making processes 

-  Optimal  use  of  available  DSS  capabilities 
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-  Interoperability  with  other  systems  as  necessary 

-  Identification  of  tactics  and  strategies 

-  Legal  issues  of  command  resposibility  in  use  of  DSS 

-  Current  and  expected  requirements  for  reliability 

-  Support  for  both  peacetime  and  combat  decision-making 

-  Decision-making  styles  of  users 

-  Likely  "areas  of  change"  for  separation  into  modules 

-  Availability/ease  of  software  and  hardware  maintenance 

-  Reliability  of  data  communications  sources 

-  Protection  against  EMP 

-  Possible  advantages  of  VHSIC 

-  Reliability  of  supporting  models 

-  User  understanding  and  acceptance  of  models 

-  Advantages  of  evolutionary  approach  to  implementation 

-  User  involvement  in  design  and  implementation 

These  are  all  considerations  which  will  involve 
approaches  and  problems  unique  for  command  and  control 
systems.  The  answers  will  not  be  found  in  current  literature 
on  DSS.  Some  suggestions  have  been  made  in  the  preceeding 
chapters,  but  specific  solutions  to  problems  will,  of  course, 
depend  on  the  particular  context  and  applications  of  each 
system.  It  is  hoped  that  this  thesis  will  stimulate  further 
research  and  interest  in  the  identification  of  methods  and 
techniques  which  will  result  in  more  capable,  reliable 
command  and  control  Decision  Support  Systems. 
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APPENDIX    A 
A   SUMMARY   OF    CURRENT    LITERATURE    ON    DSS 

The  concept  of  a  DSS  has   evolved  since  Michael  S.    Scott 

Morton's    description    in    the    early    1970's    of    a    management 

decision    system.       Today   a   standard   definition   of   a   DSS    is: 

...an  interactive  computer-based  system  which  helps 
decision-makers  utilize  data  and  models  to  solve 
unstructured  problems    [Ref.    82:    p.    40]. 

The    following   characteristics  of  a  DSS   were  determined  by 

300  users,   developers,    researchers  and  vendors  at  the  First 

International    Conference    on    Decision   Support   Systems    in   June 

1981    [Ref.    82:    p.    6]  : 

-  Aimed    at    the    less    well-structured,     under  spec i f ied 
problems   typically  faced  by  upper-level   managers 

-  Combine    use    of    models    or    analytic    techniques    with 
traditional   data   access    and    retrieval    functions 

-  User    initiated   and   controlled 

-  User-friendly   with   rapid    response 

-  Tailored     to     individual    decision-maker's    style    and 
information  needs 

-  Flexible     and     adaptable     to     accommodate    changes     in 
environment   and  decision-making   approach  of   user 

Some    additional    characteristics    of    a    DSS    as    presented    by 

authors   of    important   texts   on   the   subject: 

-  Focus   on   improving   effectiveness  of   manager's  decision 
process    [Ref.    21:    p.    2] 
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Provides  managers  with  access  to  both  internal  and 
external  data  sources  [Ref.  82:  pp.  31-32] 

Usually  requires  separate,  or  extracted,  data  base  to 
accommodate  user's  personal  and  unofficial  data  and 
information 


A.   DSS  VS.  EDP  AND  MIS 

Before  developing  further  these  DSS  concepts,  the 
following  descriptions  of  Electronic  Data  Processing  (EDP) 
and  Management  Information  Systems  (MIS)  may  help  to  clear 
some  of  the  difficulty  and  controversy  with  the  terms  DSS, 
MIS    and    EDP. 

EDP  was  the  earliest  form  of  computer  support  to 
organizations.  It  involved  automation  of  large-scale, 
batch,  operations  such  as  payroll,  invoicing,  inventory  and 
record-keeping.  The  emphasis  was  on  the  automation  of 
routine  data  or  transaction  processing.  Basic  EDP 
characteristics    include    [Ref.    82:    p.     6]: 

-  Focus    on    data,     storage,     processing,     and    flows    at    the 
operational   level 

-  Efficient    transaction   processing 

-  Scheduled   and  optimized  computer    runs 

-  Integrated   files    for   related   jobs 

-  Summary  reports   for   management. 

With  the  more  sophisticated,  third-generation  computers 
and  their  economies  of  scale,  higher-level  languages, 
operating  systems,  remote  terminal  and  query  capabilities, 
organizations   began   in   the   latter    'sixties    to  develop   more 
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integrated  sets  of  specific  data  bases.  These  data  bases 
tended  to  be  centrally  located  and  organized  by  functional 
applications.  Such  MIS  systems  are  the  most  common  type  of 
computer  support  in  organizations  today.  The  introduction  in 
the  latter  'seventies  of  complex  database  management  systems 
(DBMS)  has  permitted  the  sharing  among  functional 
applications  of  pertinent  organizational  data  and 
information.  Report-generation  capabilities  have  made 
possible  the  request  and  receipt  of  summaries  by  managers, 
often   from   their    remote    terminals. 

The  name  'MIS'  has  been  somewhat  misleading.  Most 
experts  today  contend  that  the  rigid  reports  produced  by  MIS 
have  had  little  significant  impact  on  management  decision- 
making processes  [Ref.  83:  p.  3].  Some  critics  have  gone  so 
far  as  to  imply  that  "MIS  is  a  mirage"  which  has  merely 
created  more  data  for  the  already  over-burdened  manager  [Ref. 
84:    pp.    123-132]  . 

In  any  case,  the  following  characteristics  are  usually 
associated   with  MIS    [Ref.    21:    pp.    1-2,    Ref.    82:    pp.    7,    31]: 

-  Information-focused  for   middle  managers 

-  Impacts  structured  tasks,  where  standard  operating 
procedures,  decision  rules,  and  information  flows  can  be 
reliably  predefined 

-  Integration  of  EDP  jobs  by  business  function  (personnel, 
marketing,     etc.) 

-  Inquiry   and   report-generation   capabilities 
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-  Emphasis  on  efficiency  (costs,   turn-around  time, 
personnel  reductions) 

-  Indirect  support  for  managers  decision-making,  in  the 
form  of  reports  and  access  to  data 

-  Database  restricted  to  internally-generated  aggregate  or 
historical  data. 

MIS  continues  to  hold  an  important  position  in  most 

organizations  as  is  evidenced  by  the  growing  number  of 

journals  and  articles  devoted  to  the  value  of  information, 

Information  Resource  Managers,  database  management  systems, 

and  other  such  concepts  related  to  the  development, 

maintenance  and  management  of  organizational  information 

resources.   Two  recent  and  important  factors,  however,  are 

beginning  to  stimulate  interest  in  the  more  decentralized  and 

personal  DSS  application  of  computers.   One  of  these  factors 

has  been  the  increasing  familiarity  with  and  acceptance  by 

managers  of  the  capabilities  of  the  computer.   The  second 

factor  is  the  need  to  exploit  the  new  hardware  and  software 

technology  to  help  managers  make  better  decisions  in  an 

environment  which  has  suddenly  become  characterized  by 

inflation,  uncertainty,  economic  swings  and  governmental 

regulation  [Ref.  21:  p.  4].  The  DSS  emphasis  on  effectiveness 

is  more  appropriate  for  dealing  with  change  than  is  the 

efficiency  provided  by  MIS  [Ref.  85:  pp.  19-34]. 
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B.  EFFECTIVENESS  VS.  EFFICIENCY 

While  the  ultimate  goal  of  any  manager  or  organization 
would  be  to  achieve  both  effectiveness  and  efficiency,  the 
two  criteria  of  performance  must  be  balanced  and  play 
different  roles  depending  on  the  maturity  and  environment  of 
the  various  organizational  functions.  Efficiency  implies 
maximum  output  for  minimum  input.  It  is  essentially 
programmatic  in  mature  organizations  operating  in  stable 
environments.  Effectiveness,  on  the  other  hand,  involves 
more  judgement  in  identifying  what  must  be  done  and  how  it 
must  be  done.  It  requires  adaptation  and  learning,  at  the 
risk  of  redundancy  and  false  starts.  For  example,  while 
research  and  development  can  be  thought  of  as  a  risky  and 
inefficient  investment  of  resources,  it's  purpose  is  usually 
to  provide  for  future  effectiveness  [Ref.  21:  p.  7]. 

C.  STRUCTURED  VS.  UNSTRUCTURED 

The  above  destinction  between  effectiveness  and 
efficiency  in  decision-making  is  central  to  the  concept  of 
DSS  and  their  application  to  unstructured  or  semi-structured 
problems  faced  by  managers.  Most  texts  on  the  subject  of 
DSS's  employ  Herbert  C.  Simon's  paradigm  of  problem-solving 
processes  to  explain  the  continuum  of  structured  through 
unstructured  problems.  Basically,  he  has  stated  that  the 
process  of  problem-solving  involves  three  discernable,  but 
iterative  steps  [Ref.  86:  p.  6]: 
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-  The  intelligence  phase--searching  the  environment  for 
conditions  calling  for  decision.   Gathering  data 

-  The  design  phase--inventing,  developing,  and  analyzing 
possible  courses  of  action 

-  The  choice  phase — selecting  a  particular  course  of  action 
from  those  available. 

Problems,  or  the  process  of  problem-solving,  then  can 

range  from  the  structured  to  the  unstructured,  depending  on 

how  easily  identified  are  the  information  needs  and  processes 

involved  in  each  of  these  three  problem-solving  steps. 

Structured,  or  as  Simon  calls  them,  programmed  decisions 

are: 

...repetitive  and  routine,  to  the  extent  that  a  definite 
procedure  has  been  worked  out  for  handling  them  so  that 
they  don't  have  to  be  treated  de  novo  each  time  they  occur 
[Ref.  86:  p.  7]. 

That  is,  each  phase  can  be  readily  described  and  thus  could 

be  programmed  for  computer  processing.   Transactions  for 

customers  can  thus  be  handled  completely  automatically  at 

bank  automated  cash  tellers. 

Unstructured,  or  non-programmed  decisions,  on  the  other 

hand,  are  novel  and  consequential.   Simon  continues: 

There  is  no  cut  &  dried  method  for  handling  the  problem 
because  it  hasn't  arisen  before,  or  because  its  precise 
nature  and  structure  are  elusive  or  complex,  or  because  it 
is  so  important  that  it  deserves  a  cus torn- tai lor ed 
treatment.  ...the  system  has  no  specific  procedures  to 
deal  with  situations  like  the  one  at  hand,  but  must  fall 
back  on  whatever  general  capacity  it  has  for  intelligent, 
adaptive,  problem-oriented  action. 

Most  DSS  experts  agree  that  such  problems  remain  unsupported 

by  computers  today  and  are  left  strictly  to  the  manager's 


54 


judgement  and  experience.  None  of  the  steps  in  Simon's 
decision-making  or  problem-solving  paradigm  can  be 
programmed.  In  the  intelligence  phase,  we  are  unable  to 
define  the  conditions  that  allow  us  to  even  recognize  the 
problem.  We  are  likewise  unable,  in  the  design  phase,  to 
specify  how  to  create  methodologies  to  solve  the  problem.  An 
example  of  such  a  problem  would  be  the  forecasting  of  women's 
taste  in  shoes.  No  clear  criteria  can  be  identified  for 
selecting  a  best  solution  in  the  choice  phase.  Thus,  the 
entire  problem  is  unstructured  [Ref.  21:  p.  95]. 

Most  problems,  however,  fall  somewhere  between  these  two 
extremes  and  are  called  "semi-structured"  problems.  One  or 
more  of  the  phases  of  intelligence,  design,  and  choice  can  be 
defined.  This  is  where  DSS  can  be  the  most  effective. 
Semistructured  problems  or  tasks  require  the  judgement  of  the 
manager  or  decision-maker  for  those  unspecif iable  phases,  but 
can  be  supported  by  models  or  data  which  reflect  the  known 
criteria  for  the  other  phases.  Often,  with  experience  and 
knowledge  gained  over  time,  such  problems  can  become 
sufficiently  structured  to  permit  total  automation.  Until 
then,  however,  the  man-machine  interaction  provided  in  a  DSS 
can  provide  more  effective  solutions  for  semi-structured 
problems. 


55 


D.   INFORMATION  NEEDS  DIFFER 

Three  categories  of  managerial  activity  have  been 
identified  by  Anthony  [Ref.  87:  pp.  24-27]  as  distinguishable 
in  that,  while  each  faces  semi-structured  problems,  their 
information  needs  differ  in  scope,  detail  and  currency. 
Stxat.ec[_ic  planners  need  aggregate  data  for  long-range 
planning.  Management  control  personnel  need  some  degree  of 
detail  and  operate  in  shorter-range  planning  to  translate 
strategic  plans  into  resource  requirements.  Operational 
control  personnel  use  detailed  and  current  data  for  direction 
of    actual    production. 

Anthony's  framework  has  implications  for  the  design  and 
development  of  DSS's.  First,  it  is  apparent  that  all  levels 
of  managerial  activity  are  involved  in  semi-structured 
problem  solving.  Thus  DSS  application  in  the  organization  is 
not  restricted  to  top  management.  Secondly,  given  the 
differing  information  needs  and  characteristics  associated 
with  each  level,  it  follows  that  DSS's  must  be  highly 
tailored  to  the  specific  use  or  developed  with  sufficient 
capabilities  and  flexibility  so  as  to  permit  rapid  transition 
from  one  type  of  task  or  problem  to  the  next.  It  is  also 
evident  that  the  supporting  data  base  for  DSS's  in 
operational  control  would  differ  radically  from  that  which 
would  support  DSS's  in  the  strategic  planning  area.  The  same 
can    be    said    for    the    types    of    models    incorporated    in    DSS's 
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which  support  these  different  managerial  activities. 
Furthermore,  the  design,  development  and  implementation  of 
DSS's  among  different  managerial  activity  levels  would 
necessitate  the  involvement  of  different  specialists  from  the 
systems   group    in   the   organization. 

E.       COMPONENTS    OF    A   DSS 

To  realize  the  potential  of  a  DSS  in  any  of  the  organi- 
zational contexts  described  above,  a  set  of  hardware  and 
software  components  must  be  designed  and  assembled.  While 
the  particular  design  will  depend  on  the  specific  application 
of  the  DSS,  some  generalizations  can  be  made  about  the  basic 
components.  First,  and  most  importantly,  a  DSS  involves  the 
human  decision-maker.  This  decision-maker,  usually  a  manager, 
operates  in  a  unique  environment  and  is  responsible  for  a 
given  number  of  tasks.  Figure  A-l  illustrates  the  relation- 
ship between  the  decision-maker,  the  task,  the  environment 
and  the  collection  of  components  which  make  up  a  DSS. 
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Figure  A-l.   Man-Machine  Environment 
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The  components  which  make  up  the  DSS  include  a  data  base, 
a  model  base,  and  a  dialog  language  which  interfaces  the 
decision-maker  with  the  system.  Each  of  these  components 
requires  an  associated  management  system  to  permit 
manipulation  and  access  by  the  user.  Figure  A-2  depicts  the 
logical  relationship  of  these  components  and  their  respective 
management    systems    [Ref.    82:    p.    29]. 


data   base 


user 


Figure  A-2.      DSS   Components 

1.      The  Dialog   Subsystem 

The  dialog  subsystem  of  a  DSS  is  the  DSS  in  the  eyes 
of  the  user.  All  of  the  capabilities  of  the  DSS  must  be 
articulated    and    implemented    through    the    dialog.       This    dialog 
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subsystem  can  be  further  broken  down  into  three  parts  [Ref. 
81:  2p.  30]. 

a.  The  Action  Language 

What  the  user  can  do  in  communicating  with  the 
system.  May  include  such  options  as  the  availability  of  a 
regular  keyboard,  function  keys,  touch  panels,  joy  stick, 
voice  commands,  etc. 

b.  The  Display  or  Presentation  Languages 

What  the  user  sees.  The  display  language  includes 
opinions  such  as  a  character  or  line  printer,  a  display 
screen,  graphics,  color,  plotters,  or  audio  output. 

c.  The  Knowledge  Base 

What  the  user  must  know  to  use  the  system 
effectively.  May  consist  of  a  manual  of  available  commands 
and  their  descriptions.  May  be  displayed  on  the  screen  or 
available   upon   request   with   a    "help"    command. 

The  richness  and  flexibility  of  the  dialog 
interface  will  depend  on  the  strength  and  variety  of  these 
capabilities.  The  success  of  the  entire  DSS  depends  in  large 
part  on  how  user-friendly  the  dialog  subsystem  appears  to  the 
user.  Managers  seldom  wish  to  learn  complex  languages  or  to 
memorize  illogically-designated  commands  for  functions.  The 
more  logical  the  commands  and  the  more  the  dialog  resembles 
natural  language  as  employed  in  the  context  of  the  task  at 
hand,      the     more     likely     the     system     is     to     be     used     and 
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appreciated  by  managers.  The  following  capabilities  of  a 
dialog  subsystem  further  enhance  the  chances  of  success  of 
the  DSS  [Ref.  82:  p.  31]  : 

-  The  ability  to  handle  a  variety  of  dialog  styles,  and   to 
shift  among  them  at  the  user's  choice 

-  The  ability  to  accommodate  user  actions  with  a  variety  of 
input  devices 

-  The  ability  to  present  data  with  a  variety  of  formats  and 
output  devices 

-  The  ability  to  provide  flexible  support  for  the  user's 
knowledge  base. 

Dialogs  can  take  the  form  of  question  and  answer 
routines,  report  format  blanks,  menu  selections,  or  command 
languages.  Most  DSS  will  incorporate  some  combination  of 
these  for  wider  application  and  increased  flexibility.  They 
usually  include  other  conventions  to  provide  error  messages, 
acknowledgements,  verification  requests,  default  values,  and 
possibly  override  features  for  experienced  users  [Ref.  82:  p. 
207]  . 

The  choice  of  a  dialog  form  is  an  important 
decision  in  the  design  of  a  DSS  for  two  reasons:  (1)  an 
inappropriate  format  will  discourage  use  of  the  DSS  and 
thereby  reduce  its  effectiveness,  and  (2)  the  dialog 
component  of  a  DSS  often  constitutes  the  largest  percentage 
of  the  total  code  in  a  DSS,  and  thus  the  most  expensive  [Ref. 
82:  p.  217]. 
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The  design  of  the  dialog  component  should  begin 
with  an  analysis  of  the  decision-making  process  and 
environment  of  the  user.  Such  an  analysis  would  identify  the 
communications  style  of  the  user,  the  response- t ime 
requirements,  the  desired  outputs,  and  the  required  input 
parameters.  The  goal  should  be  to  provide  effective 
representations  or  displays  and  understandable  control 
mechanisms.  In  many  cases,  software  packages  can  be 
purchased  'off  the  shelf  to  meet  the  needs  of  the  user  and 
reduce  development  costs.  Some  applications,  on  the  other 
hand,  are  so  unique  as  to  require  programming,  either  in- 
house   or    by   a   contractor. 

The  effectiveness  of  a  chosen  dialog  can  be 
measured  by  number  of  errors,  learning  time,  user  perceptions 
and,  although  more  difficultly,  by  effect  on  the  decision- 
making process  and  its  results,  (i.e.,  number  of  alternatives 
analyzed)  [Ref.  82:  p.  207]. 
2.      The   Data   Subsystem 

The  data  subsystem  of  a  DSS  is  visible  to  the  user 
only  through  the  use  of  the  dialog  to  access  desired  data. 
Recent  advances  and  developments  in  database  management 
provide  a  number  of  powerful  functions,  often  in  the  form  of 
"off  the  shelf"  packages.  However,  the  data  base  of  a  DSS 
differs  from  that  of  a  MIS  in  two  significant  ways;  it  is 
dependent  on  external   sources   as    well  as   internally-generated 
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data,  and  it  must  accommodate  individual  user's  needs  for 
storing  and  rapidly  accessing  both  personal  and  corporate 
data.  For  these  reasons,  it  is  often  necessary  to  create  for 
the  DSS  a  separate  data  base,  part  of  which  is  extracted  from 
the  general  corporate  data  base  (or  MIS)  and  part  of  which  is 
drawn  from  external  data  sources.  Figure  A-3  illustrates  the 
concept  of  the  extracted  data  base  [Ref.  82:  p.  32], 
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Figure  A-3.   Extracted  Data  Base 
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Carlson  and  Sprague  identify  some  desirable  features 
of  a  DSS  data  base  subsystem  [Ref.  82:  p.  32]  : 

-  The  ability  to  combine  a  variety  of  data  sources  through 
a  data  capture  and  extraction  process 

-  The  ability  to  add  and  delete  data  sources  quickly  and 
easily 

-  The  ability  to  portray  logical  data  structures  in  user 
terms  so  that  the  user  understands  what  is  available  and 
can  specify  needed  additions  and  deletions 

-  The  ability  to  handle  personal  and  unofficial  data  so 
that  the  user  can  experiment  with  alternatives  based  on 
personal  judgement 

-  The  ability  to  manage  this  wide  variety  of  data  with  a 
full  range  of  data  management  functions 

When  the  user  of  a  DSS  invokes  the  dialog  to  gain 
access  to  the  data  base,  it  is  the  Database  Management  System 
(DBMS)  which  actually  translates  the  request  and  accesses  the 
data  base  to  create,  maintain,  update,  or  display  data  as 
instructed.  In  some  DSS  designs  it  may  be  possible  to  share 
the  DBMS  which  serves  the  central  corporate  information 
system.  Usually,  however,  it  is  wise  to  incorporate  in  the 
DSS  a  separate  DBMS  for  faster  response  time  and  more 
flexible  data  retrieval  functions. 

Conversely,  it  is  seldom  recommended  that  the  DSS 
design  should  attempt  to  create  an  entirely  separate  data 
base  of  its  own.  Instead  it  should  take  advantage  of  the 
involved  and  time-consuming  efforts  already  invested  in  the 
corporate  data  base.  This  can  be  accomplished  by  referencing 
the  corporate  data  base  whenever  data  is  needed  or  by 
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periodically  extracting  needed  elements  into  a  smaller  and 
separate  DSS  data  base.  Reliance  on  the  corporate  data  base 
for  internally-generated  data  needs  results  in  decreased 
costs,  more  consistent  and  reliable  information,  simplified 
DSS  design  and  development  and  fewer  security  problems  [Ref. 
82:  p.  223]. 

Data  resident  in  the  data  base  can  be  organized  in  a 
number  of  ways.  Generally,  a  DBMS  is  designed  specifically 
for  the  one  particular  organization  of  data  within  the  data 
base.  Thus,  the  selection  of  the  DBMS  for  a  DSS  depends  on 
the  data  model  used  in  the  corresponding  data  base,  which,  as 
described  above,  is  probably  already  functioning  within  the 
organization. 

The  various  data  models  are  described  briefly  below: 

-  Record  Model:  Data  is  organized  by  records  which  are 
composed  of  related  fields.  Usually  each  record  has  one 
or  more  key  fields  which  permit  sorting  of  the  data  by 
attributes  recorded  in  that  field.  For  example,  each 
customer's  record  identifies  all  loan  accounts 
corresponding  to  that  customer. 

-  Relational  Model:  Data  is  organized  in  records  and 
fields,  where  records  are  grouped  by  relation.  For 
example,  all  car  loan  accounts  are  grouped  separately 
from  all  signature  loan  accounts. 

-  Hierarchical  Model:  Data  is  organized  as  in  the 
relational  model  but  the  various  groups  are  stratified, 
with  upper-level  groups  having  access  to  relational 
groups  at  lower  levels.  For  example,  the  upper-level 
group  of  all  loan  accounts  by  number  can  access  the 
lower-level  groups  of  associated  customers  by  loan 
account  number.  This  model  creates  data  redundancy  and 
can  be  difficult  to  alter  or  update,  but  provides  other 
offsetting  benefits  such  as  faster  access  and  less  need 
for  the  user  to  understand  the  data  organization. 
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-  Network  Model:  Much  like  the  hierarchical  model  except 
that  data  redundancy  is  eliminated  or  reduced  by  the  use 
of  logical  versus  actual  records.  Pointers  are  used  to 
direct  search  procedures  to  the  actual  location  of 
desired  records  instead  of  duplicating  them  wherever  they 
are  related  to  a  group. 

-  Rule  Model:  Often  called  'knowledge-based'  systems, 
these  models  organize  data  and  information  in  the  form  of 
rules  or  conditions.  For  example,  when  asked  to  compute 
a  credit  rating,  the  DBMS  for  a  rule  model  would 
determine  the  necessary  data  input  based  on  its  rules  for 
such  a  computation,  would  access  or  request  input  of  such 
data,  and  would  follow  a  predetermined  set  of  "if  -  then" 
production  rules  to  examine  assets,  liabilities,  etc.  in 
order  to  determine  loan  elligibility.  This  type  of  model 
is  gaining  increased  recognition  as  it  can  support  the 
speed  and  self-updating  requirements  of  Artificial 
Intelligence  [Ref.  88:  p.  560]. 

Another  criteria  for  selecting  a  DBMS  for  a  DSS  is 

the  required  number  and  variety  of  data  operations  and 

integrity  constraints.   Data  operations  include  such 

capabilities  as: 


dictionary  views 

creation  protection 

deletion  sharing 

update  recovery 

query  file  optimization 


Several  other  DBMS  choice  criteria  are  listed  and 
briefly  explained  below.  It  is  important  to  remember  that 
the  more  capable  the  DBMS,  the  more  overhead  will  be  involved 
in  processing  time  and  in  development  costs.  The  need  for 
these  capabilities  must  be  weighed  against  both  the  overall 
development  costs  and  the  differences  in  processing  or 
response  time  to  the  user. 
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-  Support  for  Memory:  Workspaces  for  intermediate  results; 
libraries  for  saving  workspaces;  links  or  indices; 
triggers  to  remind  decision  makers  of  needed  data  or 
operations 

-  Data  Reduction:  Abstraction  from  large  amounts  of 
data  through  subsetting,  combination,  or  aggregation 

-  Detail  Focus:  To  permit  managers  to  focus  on  necessary 
level  of  detail 

-  Multiple  Source:  Ability  to  access  various  internal  and 
external  data  sources 

-  Catalogue  of  Sources:  To  identify  for  the  manager's 
intelligence-gathering  phase  of  decision-making,  all 
available  sources  of  relevant  information 

-  Wide  Time  Frame:  To  permit  analysis  of  both  historical 
data  and  projections  of  current  data  into  the  future 

-  Private  Data  Bases:  At  least  part  of  the  DSS  data  base 
should  be  accessible  only  by  the  user 

-Varying  Degrees  of  Accuracy:  At  times  the  manager  may 
need  precision;  other  times  he  may  prefer  to 
"satisfice"  and  use  estimates  in  order  to  save  time  on 
less  critical  decisions.  Should  provide  indication  of 
degree  of  accuracy  of  data  supplied  user 

-  Random  Access:  Fast  access  to  desired  data.  Serial 
access  probably  too  slow  and  frustrating  for  managers 

-  Transparency  to  the  User:  Users  generally  not  skilled  or 
interested  in  programming  languages.  User  should  be  free 
of  need  to  know  details  of  data  storage 

3.   The  Model  Subsystem 

While  decision-making  models  have  been  developed  for 

many  years,  managers  seldom  became  adept  or  interested  in 

their  use  and  have  relied  instead  on  their  own  heuristic 

methods  of  problem-solving.  The  integration  of  appropriate 

models,  data,  and  a  method  of  communication  and  flexible 

manipulation  among  models  and  data  as  permitted  by  a  DSS 
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provides  managers  with  the  flexibility  and  and  ease  of 
manipulation  which  was  not  available  with  the  independent 
models.  Thus,  managers  provided  with  DSS's  are  much  more 
likely  to  develop  an  appreciation  for  the  "what-if"  analysis 
capabilities  of  models  or  simulation  [Ref.  82:  p.  258]. 

The  modeling  component  of  a  DSS  is  the  primary  tool 
for  supporting  the  design  and  choice  phases  of  decision- 
making. These  phases  include  such  activities  as  [Ref.  82:  p. 
260]  : 

*projection  *deduction 

♦analysis  *creation  of  alternatives 

'•"'comparison  *optimization 

♦simulation 

In  general,  support  for  these  activities  depends  on  feedback 

and  interaction  between  the  decision-maker  and  the  modeling 

component.   The  DSS  should  allow  the  examination  of 

intermediate  results,   the  accommodation  of  subjective 

judgement,  and  modification  of  input  or  model  choice  as  the 

problem,  or  the  user's  perception  of  the  problem,  changes. 

Other  key  capabilities  required  of  a  DSS's  modeling  component 

include  [Ref.  82:  p.  33]: 

-  The  ability  to  create  new  models  quickly  and  easily 

-  The  ability  to  access  and  integrate  model  building 
blocks" 

-  The  ability  to  catalogue  and  maintain  a  wide  range  of 
models  to  support  all  levels  of  users 

-  The  ability  to  interrelate  these  models  with  appropriate 
linkages  through  the  data  base 


67 


-  The  ability  to  manage  the  model  base  with  management 
functions  analogous  to  data  base  management  (e.g., 
mechanisms  for  storing,  cataloging,  linking,  and 
accessing  models) 

Barbosa  and  Herko  identify  several  other  important 

requirements  of  a  DSS  modeling  component  [Ref.  89:   pp.  1- 

12]  : 

a.  Interface 

The  user  should  be  able  to  work  in  the  problem- 
solving  environment  without  unnecessary  distractions.  The 
user  should  not  have  to  interrupt  this  process  and 
laboriously  supply  some  control  parameters  before  continuing. 

The  control  parameters  should  be  expressed  in 
terms  with  which  the  user  will  be  familiar.  He  or  she  should 
be  able  to  think  about  only  those  parameters  that  have  a 
direct  bearing  on  the  problem-solving  process. 

b.  Control 

The  user  should  be  given  a  spectrum  of  control. 
If  possible,  the  system  should  support  manual  operation  as 
well  as  fully  automatic  operation.  This  permits  the  user  to 
select  the  level  of  algorithmic  operation  that  seems  most 
suitable.  It  also  enables  the  user  to  learn  more  easily  by 
allowing  him  or  her  to  proceed  as  slowly  as  desired. 

The  control  mechanism  should  allow  the  user  to 
introduce  subjective  information  as  demanded  by  the  problem 
solution  process.  It  should  not  require  the  user  to  specify 
all  constraints  a  priori.   This  direct  human  control  of  the 
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solution  process  can  make  up  for  deficiencies  in  the 
algorithm  and  will  often  permit  the  system  to  contain  a 
simpler  algorithm,  frequently  resulting  in  smaller 
information   burden  on    the   user. 

c.  Flexibility 

The  algorithmic  and  manual  operations  should  be 
interchangeable  in  the  sense  that  the  user  can  develop  part 
of  a  solution  via  manual  methods  and  then  continue  with  the 
algorithm,  or  vice  versa.  This  statement  implies  that  the 
range  of  all  operations  can  be  cascaded  in  an  arbitrary  way. 
Both  flexibility  and  control  allow  the  user  to  construct  a 
solution  process  that  best  suits  the  problem.  This  idea  of 
interchangeability  of  operations  is  deceptively  simple,  but 
it  has  far-reaching  implications.  This  is  the  manner  by 
which  flexibility  and  control  are  achieved.  Thus  a  creative 
solution  process  can  be  composed  of  a  sequence  of 
subprocesses. 

d.  Feedback 

The  system  should  provide  sufficient  feedback  so 
that  the  user  is  fully  cognizant  of  the  state  of  the  solution 
generation  process  at  all  times.  This  feedback  is  essential 
for  supporting  human  control  of  the  process. 

The  design  process  itself  should  make  use  of 
feedback.  Valuable  information  can  be  derived  from 
introduction  of  the  initial  system  or  prototype  to  the  users. 
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Their  feedback  should  be  especially  meaningful  in  the  area  of 
usability. 

The  modeling  component  will  be  comprised  of  a 
model  base,  or  library,  and  a  software  system  to  manage  the 
models  in  the  library.  This  management  software  is  known  as 
the  Model  Base  Management  System  (MBMS).  It  also  serves  to 
interact  with  both  the  DBMS  and  the  DGMS  of  the  data  base  and 
dialog  components,  respectively. 

The  model  base  will  contain  both  canned  and  user- 
built,  ad-hoc  models  designed  to  support  a  variety  of  tasks 
at  any  or  all  of  the  three  levels  of  managerial  activity. 
Smaller  models  may  be  used  as  building  blocks  for  creating 
larger  ones. 

The  MBMS  will  handle  the  storage,  retrieval, 
manipulation,  creation  and  operation  of  the  models  in  the 
model  base.  It  will  interact  with  the  dialog  component  to 
permit  the  user  to  accomplish  interactive  modeling  which 
permits  interruption,  sequence  variation,  and  parameter 
changes.  It  will  interact  with  the  data  component  of  the  DSS 
to  access  input  data,  to  update  data  based  on  results,  to 
accept  updates  necessitated  by  changes  in  the  data  base,  and 
to  store  intermediate  results  [Ref.  82:  p.  263]. 
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F.   SUMMARY 

DSS  imply  the  integration  and  management  of  data,  models 
and  an  interactive  dialog  to  extend  a  user's  judgement  by 
permitting  analyses  of  data.  DSS  are  not  replacements  for, 
but  rather,  aids  to  the  human  decision-making  processes. 
Each  application  will  involve  the  tailoring  of  the  user's 
data  requirements  to  a  specific  decision-making  context. 
Choices  of  database  management  design,  dialog  styles  and 
supporting  models  are  therefore  highly  context-dependent. 
The  goals  of  applicability,  flexibility  and  ease  of  use  are 
common  to  all  DSS.  The  degree  to  which  these  goals  are 
realized  in  the  design  and  integration  of  the  basic 
components  will  largely  determine  the  success  or  failure  of 
the  system. 
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